/ok-to-test

seems the build is failing. I guess the amlogic script needs something extra

seems the build is failing. I guess the amlogic script needs something extra

I believe the amlogic script is calling an amd64 binary, given that it is assumed that the build environment for u-boot is amd64. This would also explain why it works on my machine where binfmt_misc is used to be able to run both amd64 and arm64 binaries simultaneously in the same builder.

Any chance the arm64 builder could be updated to support running amd64 binaries? It'll be slow when it's used, but for this particular use case it shouldn't really matter.

Any chance the arm64 builder could be updated to support running amd64 binaries?

we use dedicated arm64 builder for arm

anyways what binary it's calling, there could be arm64 variant of it

I would also check if the scrip is just creating a final binary blog with BL31 appended, then should be easy to change it to use dd

another option is to build the u-boot for odroid in the amd64 section only https://github.com/siderolabs/pkgs/blob/main/u-boot/pkg.yaml#L20 in the else part of this

we use dedicated arm64 builder for arm

Yes, I know. I'm wondering if that builder can be updated to include support for amd64 binaries for cases like this.

anyways what binary it's calling, there could be arm64 variant of it

It's calling aml_encrypt_g12a, which is vendored into the repo.

I would also check if the scrip is just creating a final binary blog with BL31 appended, then should be easy to change it to use dd

The script is signing the binaries in addition to other things. This isn't something that can be easily replaced with dd, as far as I can tell.

Yes, I know. I'm wondering if that builder can be updated to include support for amd64 binaries for cases like this.

you can build the whole u-boot for odroid in the amd64 section, and use CROSS_COMPILE option i believe

you can build the whole u-boot for odroid in the amd64 section, and use CROSS_COMPILE option i believe

Right, but how do we handle this further down the chain? The installer image is built with --platform=linux/arm64, for example.

It seems like it would be a lot cleaner to just enable binfmt_misc on the arm builder and use it sparingly rather than having to massively complicate the build chain for this special case.

binfmt_misc won;t work as the ci is on talos and the KSPP requires it to be disabled. The installer image can refer the amd64 in the talos dockerfile

Would this also make talos work on an Odroid C4 and Odroid N2+?

@mirceanton The C4 and HC4 are identical with the exception of the SATA ports, so yes. I'm not as sure about the N2+, but I believe the answer is also yes.

All of those boards have support in the upstream kernel, so it's mostly a question of packaging Talos and getting the bootloader situation sorted.

@DWSR this can be now moved to using an overlay. probably a new repo, since amlogic seems to be different from allwinner.

See this: https://github.com/siderolabs/overlays/